With increased use of the Internet to transmit secure information, such as credit card information in an e-commerce transaction, banking information for online banking applications, stock trading information or the like, concerns over security have become more prevalent. Similarly, the Internet has seen an increase in the use of Virtual Private Networks, which utilize the Internet as a communications media but impose security protocols onto the Internet to provide secure communications between network hosts. Typically, these security protocols are intended to provide “end-to-end” security in that secure communications are provided for the entire communications path between two host processing systems.
To address these and other issues, the Internet Protocol Security Architecture (IPsec) was developed. IPsec is a Virtual Private Network (VPN) technology. Typically, IPsec uses symmetric keys to secure traffic between peers. These symmetric keys are generated and distributed by an Internet Key Exchange (IKE) function. IPsec uses security associations (SAs) to provide security services to traffic. SAs are unidirectional logical connections between two IPsec systems which may be uniquely identified by the triplet of <Security Parameter Index, IP Destination Address, Security Protocol>. To provide bidirectional communications, typically, two SAs are defined, one in each direction.
SAs are managed by IPsec systems maintaining two databases: a Security Policy Database (SPD) and a Security Associations Database (SAD). The SPD specifies what security services are to be offered to the IP traffic. Typically, the SPD contains an ordered list of policy entries which are separate for inbound and outbound traffic. These policies may specify, for example, that some traffic must not go through IPsec processing, some traffic must be discarded and some traffic must be IPsec processed.
The SAD contains parameter information about each SA. Such parameters may include the security protocol algorithms and keys for Authentication Header (AH) or Encapsulating Security Payload (ESP) security protocols, sequence numbers, protocol mode and SA lifetime. With IPsec in place, for outbound packets, the SPD is consulted to determine if IPsec processing is required or if other processing or discarding of the packet is to be performed. If IPsec is required, the outbound SAD is searched for an existing SA for which the packet matches the profile. If a SA is found or after negotiation of a SA, IPsec is applied to the packet as defined by the SA and the packet is delivered. For inbound packets, the inbound SAD can be directly consulted to determine if IPsec or other processing is required. If IPsec is required, the SAD is searched for an existing security parameter index to match the security parameter index of the inbound packet. The SA is then used to IPsec process the inbound packet. A final check against inbound policy is made after inbound processing to verify the validity of the resulting packet.
As is evident from the above discussion, a significant amount of processor resources may be devoted to security processing. Both IPsec processing and Secure Socket Layer (SSL) processing may, for example, require encryption and decryption of data as well as application of security policies to that data. Such security processing may adversely affect throughput of communications. For example, security processing may reduce the number of transactions an online banking system may receive in a given period of time. Similarly, throughput concerns may become an issue in “real time” applications of the Internet, such as the transmission of video or audio over the Internet. Thus, it may be beneficial to provide dedicated processing capabilities to perform the complex tasks associated with encryption, which may improve the performance Internet security processing and, thereby, improve throughput.
One further difficulty with particular types of Internet traffic relates to the sequence or order in which packets are received. For example, in typical Internet traffic, packets may be transmitted and received out or order and then re-ordered at the receiving endpoint. In the current Internet Protocol (IP) standard, this reordering is allowed at the IP layer, and the end-units would re-order the packets if necessary before passing data to the application layer. However, recent introductions of voice and video data over the IP network have increased the importance that packets are not reordered in the network. The latency and overhead required to re-order the packets at the end stations may not be acceptable in these real-time applications, and may frequently result in dropped packets.
In order to improve cryptographic performance, aggregation may be utilized in the architecture of a cryptographic accelerator. Through the use of parallel processing techniques, increased processing performance may be achieved. However, in conventional parallel processing of cryptographic packets, packets of different lengths or requiring different processing within the crypto units may take different amounts of time to be processed. Thus, packets may be reordered when traversing the parallel cryptographic system. For instance, if a sequence of packets of sizes 3x, 2x and x are provided to parallel cryptographic processing units at the same time they will finish in order x, 2x and 3x (assuming that the transformations required for each packet and the processing performance of the crypto units is similar). If these packets are simply output in the order in which processing is completed, the packets will have been re-ordered. Thus, conventional aggregation techniques for parallel processing may be unsuitable for use in cryptographic processing.